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1. Introduction 

Cabie Retu.-n Channel (CRC) system is a system designed to deliver interactive services to cable Set Top 
Boxes (STE'.'s) and optionally Cable Modems (CM's). 

Access Sen'ice Providers (ASP's) and Internet Service Providers GSFs) strongly require the authentication, 
authorizauon and subsequently billing of users entering their networks and using their services respectively. 
This dociinieat proposes an authentioalion, authorization and accounting architecture based on the widely 
used and a<:cepted Remote AuthentUscOion Did In User Service (RADIUS) [9], [lO] protocol. 
The propo<al is based on the Direct-IP protocol stack which will be mandatory (n the next ETS300.800 [I] 
standard. The current ETS300.802 [2] protocol standard used for DVB compliant ^e^--^^^^^^ 
prescribes the use of PPP [4], [6], [7] in the middle layers of the protocol Jtaok between the rNA and STB. 
However, ihe next vereion of the ETS300.80C will require a protocol stack for the interaction channel 
whereby tl- is PPP layer is removed. This protocol stack is called: direct-IP. 

1.1 Objectives and Scope 

The objective and scope of this document is to propose an authentication, authorization and accounting 

arcKitectuie based on RADIUS for the Cable Return Channel system (CRC system). 

The hitent loa of this proposal is to cover the needs of both access service providers and internet service 

providers. 

Intended audience are product managers, architects and. developers that participate in the development of 
the Interactive Network Adapter (INA) and STB of the interactive cable system. 

1.2 References 

[1] ETS300800, Distal Video Broadcasting (DVBJj DVB Interaction channel far Cabie TV 

distribution systems (OA TV), EBU/CENELEC/ETSI-JTC, 12*^ August 1997 
[2] ETS3 00802, Digital Video Broadcasting (DVB); Network-independent protocols for DVB 

interactive services, EBU/CENELEOETSI-JTC. November 1997 
[3] Comer, DOUGLAS E., Internetworking with TCP/IP. Vol 1: Princ^es, Protocols, and 

Architecture, Prentice Hall, Englewood Cliffs, New Jersey 
[4] McGregor G.. The PPP Internet Protocol Control Protocol (IPCP). RFC 1 332, Merit, May 1992 
[S] B. Lloyd. L&A, W. Simpson. PPP Authentication Protocols. RFC 1334, DayDreamer. October 

1992 

[6] Simpson, W., PPP LCP Extensions, RFC 1 570, DayDreamer, January 1994 

[7] Simpson. W., The Pomt-to-Point Protocol (PPP). RFC 1661, DayDreamer, July 1994 

[8] Simpson, W., PPP Challenge Hmdshake Authentication Protocol (CHAP). RFC 1994, 

DayDreamer, August 1996 
[9] C. Rigney Livingston, A. Rubens Merit, W. Simpson Daydreamer, S. Willens Livingston, Remote 

Authentication Dial In User Service (RADIUS), RFC 2138, April 1997 

110] C. Rigney Livingston, RADIUS Accounting RFC 2139, April 1997 
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1.3 Acronyms 



ASP Access Service Provider- 

BNA Broadcast Network Adapter. 

CM Cable Modem. 

CRC Cable Return Channel. 

D VS Digital Video Systems. 

HFC Hybrid Fiber Coax, 

IN A Interactive Network Adapter. 

IP Internet Protocol [3]. 

ISP Internet Service Provider. 

MAC Medium Access Control [1] 

RADIUS Remote Authentication Dial In User Service [9], [10]. 

RF Radio Frequency. 

STB Set Top Box* 

TCP Transfer Control Protocol [3]. 

UDP User Datagram Protocol [3] . 



2. Requirements 

The proposed authenticatioiu authorization and accounting architecture is based on the following 
rcquiremer.ts: 

• The anshitecture shall be based on the RADIUS [9], [10], as this is the standard for authentication, 
author zarion and accounting within the Internet community. 

• The architecture shall offer authentication, authorization and accounting on a per session basis- 

• The architecture shall support different applications running in parallel. 

• The architecture shall allow the use of different accounting policies e-g. one for web'bn\^sing and 
anotlier for IP-telephony. 

m The architecture sliall allow each ISP or ASP to do its own authentication, authorization and accounting. 

• The architecture shall allow STB's which doesn't contain functionalit>' for this architecture to enter the 
cable network. However, security measures shall be taken that they can not access (accountable) 
services &r which they have to be authenticated and authorized. 

• The aicliitecture shall have no impact on the current ETS3O0.800 [1], ETS300,802 [2] and the next 
version ^^f the ETS300.800 standards. 

• The ajxshitecture shall be secure i.e. users can not circumvent authentication, authorization and 
accou itmg e g. by ^ hacking^ the STB or CM. 

• The ai-chitecture shall allow authentication, autiiorization and accounting for the interaction network as 
well as the broadcasting network* 



3. System Model 



3.1 Reference Architecture 

The follo\\ing diagram presents a block diagram of the reference architecturs for autheotication, 
authorlzatian and acwunting within the CRC system: 




In the reference architecture, two logical chazmels are established between the STB and service provider: the 
broadcast channel and the interaciion channel. The unidirectional broadcast channel which is part of the 
Broadcasimg Deliyery Network includes video, audio and data, The bi-directional interaction channel which 
is part of the Interaction Network is intended for interaction purposes. It is formed by a return interaction 
path and a forward interaction path. The forward interaction path maybe embedded into the broadcast 
channel. It: \s possible that the forward path of the interaction channel is not required m some simple 
implemenat-ions which make only use of the broadcast channel for carrying data. Physically, the 
broadcasting delivery network and interaction network are laid over one HFC netwoHf i.e. the STB has one 
RF conne<stion to the HFC net^'ork. 

The Imervction Network Adapter (INA) implements tiic functionality <AtiNetwork Access Server (NAS) for 
allowing SlTB's and Cable Modems to access tiie IP network (3] over the HFC network. It embeds the 
interactive^ (IP) data in the interaction channel. 

The Broatlcast Network Adapter (BNA) embeds the (IP) data in the broadcast channel. 

RADIUS servers are responsible for receiving session requests from the INA, authenticating the STB (s,e. 
STB session), and subsequently returning all configuration information necessary to deliver the service to 
the STB in question. 



Optionally, a RADIUS server can act as a proxy client to other RADIUS servers or other kinds of 
authentics.tion servers. 



4. Direct-IP based Architecture (Proposal) 

The here ptoposed direct-IP based architecture for auAenticalion, aathorizatLon and accounting is a solution 
for the situation that PPP is removed fronr* the protocol stack. So, PPP can no longer be used for 
authenticat on and authorization [5], [«]. This situation will arise with the next version of the ETS300.800 
standard wherein, so called: direct-IP is mandatoiy and PPP optional (Subsequently, PPP will be removed 
from this slandard!). 

The proposal i& to add RADIUS functicnattty to the Set-Top-Box and Cable Modem i.e. it looks like a 
RADIUS client is buUt into the STB or CM. This can be done by adding RADIUS functionality to the STB 
and CM xn ddle ware e.g. MediaHighWay layer cf Canali-. 



4.1 Reference Model 

The follo>\!ng diagram present* a reference model for this architecture: 
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The STB ^DIUS client communicates with the RADIUS proxy insid* the INA which on its turn 
cotnmunicates with the RADIUS server of the ISP or ASP in question. The INA includes functionality for 
accountin % and an IP filter. 

The STB Jses a SmartCard which contains for each user an ID, password and a CHAP secrecy. At set-up of 
the connection, this information is used to authenticate and authori2e the STB by the RADIUS server. 

The INA .softtains a RADIUS secrecy for securing the connection with the RADIUS server. The RADIUS 
secrecy is used to add to each RADIUS rnessagc a cryptogtaphfc message digest of die payload of the 
message, so that the RADIUS server can verify that the message is generated by an authorized INA and not 
tempered 

The data 'jase of the RADIUS server contains for each STB ue. SmartCard, the ID, password and CHAP 
secrecy. Furthermore, it contains for each INA the RADIUS secrecy for autiienticating the RADIUS 
messages coming from the INA in qu^rtion and vice versa. 
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4.2 STEt RADIUS Client 

The RADIUS client inside the STB implements all necessary functionality for RADIUS authentication, 
authorixaticm and accounting. It is capable of generating and handling all RADIUS messages i.e. Access- 
Request, Access-Accept, Access-Reject, Access-Challenge md the accounting messages: Accounting-Request 
zxidAccaur ting-Response plus the necessary message attributes. 

RADIUS tnessages will only be exchanged on the Interaction C/wnne/ between the STB and INA. 

The STB Icicws the IP address of the RADIUS server, it needs for authorization, authentication and 
accounting If this is not the case, the STB uses the IP broadcast address: 253.235.255.255 and the proxy 
RADIUS of the INA fills in the IP address of the default RADIUS server. (RADIUS uses the well know 
UDP port r umber 1812 for RADIUS authentication and authorization and 1813 for RADIUS accounting.) 

The RADP JS message attribute; 'NAS-Porf can be used to address the different STB applications. 

The RADUS message attribute: 'NAS-lP-Address' is used to inform the designated RADIUS server of the 

IP address of the RADIUS client i.e, STB. 

4.3 STB Protocol Stack 

The foUovv ing protocol stack is used for the direct-IP archit^^cture: 



Application 



RADIUS ' MediaHlgWAtey 



Client 
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TCP 
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Tlie RADIUS client is on top of UDP/IP [3]. It can be part of e-g. MedaaHighWay adaptation layer. More 
than one STB appHcattion can make use of the RADIUS functionality, so that for each application a 
RADIUS i;ession can be executed Le. authentication, authorization and accounting can be done. 
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S. Inteiractions 

The interactions between the RADIUS Server, INA and STB is described with the aid of Message Sequence 
Charts (MJSIC). 

5.1 Normal Authentication, Authorization and Accounting Sequence 

The MSC below shows the normal interactions between the STB? INA and RADIUS server for 
authenticating* avthorking and acwunting. This sequence is executed after a STB has successfully signed- 
on, on MAC layer: 
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The follo'iving steps are executed: 

1 . The S<TB sends a DHCP request message to get an IP address. 

2. The INA replies whh a DHCP reply message containing an IP address to be used by the STB, 
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3 . The STB sends a RADIUS access request message for entering the cable network. 

4. The IN A forwards this request message to the appropriate RADIUS server. 

5 . The R/.DIUS server generates a RADIUS challenge message to authenticate the STB. 

6. The STB replies with a RADIUS access request message containing the RADIUS challenge respoiise. 

7. If the c lallenge response is okay, the RADIUS server replies with a RADIUS access accept message. 
This sijpials the INA and STB that the STB is allowed to enter the cable network. 

8. When the service in question is started, the STB sends a RADIUS accounting request message to turn on 
the acc>3unting for the service in question. 

9. The Ri^ J3IUS server will respond with a RADIUS accounting response message. This message will 
adjust the IF-filter of the INA in such way that the IP-datagrams of the service (and STB) in question 
can be forwarded by the INA. 

10. When Ihe service has finished, a RADIUS accounting request message to turn ofT accounting, is send to 
the RADJUS server. 

11. When ihi! response is received from the RADIUS server, the IP-filter is adjusted in such way that the IP 
datagrams of the service in question is blocked by the INA* 

Note that this is a rough indication of how the interaction between the STB, INA and RADIUS server can be 
done. Many variations can be intxodticed on this sequence. 

5.2 Rejected STB Sequence 

The MSC below shows the interactions between the STB, INA and RADIUS server for the case that the STB 
is rejected: 
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The follov/ing steps are executed: 

1 . Tho STB sends a DHCP requKtt message to get an IP address. 

2. The UiA replies with a DHCP r«ply mesaage cciitainiiig an IP address to be used by the STB. 

3. The SFB sends a RADIUS access request message for entering the cable network. 

4. The Its A forwards this request to the appropriate RADIUS server. 

5. The RADIUS server generates a RADIUS challenge to authenticate the STB. 

6. The STB replies with a RADIUS access request message containing the RADIUS challenge response 

7. When the challenge response is not okay, the RADIUS server replies with a RADIUS access reject 
messe ge. This signals the INA and STB that the STB is not allowed to enter the cable network. 

After some time the STB retries to enter the network again. This can be handy for the case that the access 
permissions of ttie STB has changed in the meantime. For example, the user has called the service center of 
the access service provider to update its permissions. 

The IP-filtef inside the INA will pravem that unauthorized data enters cable network. 

Note that this is a rough indication of how the interaction between the STB, INA and RADIUS server can be 

done. Maiy variations can be introduced on tiiis interaction. 
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6. Discussion 

With PPPj only the PPP 'pipe^ (i e. connection) is authenticated and authorized. Furthermore, *e used 
aocQunting is the same for all types of services i-e. it can not support different accounting policies for 
different services. In the direct-IP architecture, the authentication, authorization and accounting can be done 
on a per seivioe basis* 

By using an IP-filtcr and by doing accounting outside the STB, the proposed architecture 15 expected to be 
secure i.e. lisers can not circumvent authentication, authorization and accounting by using an 'phony' STB, 
The IP-filt»T will keep out data of unauthorized STB^s. The IP-filter will be controlled by the RADIUS 
messages from the RADIUS server in question. 

The proposed architecture can support homogeneous networks with cable modems and STB's from third 
parties. 

(Note that •;he proposed architecture also works with PPPl) 



Claims 



1 » CDmmunication system comprisiag a client station being connectable to a server 
station via a IP based network, characterized in that the communication system comprises 
authentication means operating at the application layer. 

2. Communication system according to claim 1> characterized in that the authentication 
is based on the RADIUS protocol. 

3. Client station for use in a communication system according to claim 1. 

4. Server station for use in a communication system according to claim 1 . 

5. Signal carrying authentication protocol information to be used in the system according 
to claim 1 . 
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